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(57) Abstract 

Methods are disclosed for gathering information finom different sources to be used to automatically fill in online forms. The information 
is collected using a persona of an individual. A persona is created by filtering a larger set of raw data for that user so that only certain fields 
are allowed to be seen and used by others. An individual can have several personas, each assigned to a particular other individual, such as 
a family member or a friend. Hie individual allowing one of his personas to be shared is the information provider and the user requesting 
the information is the information requester. The information is taken from both the provider and requester, and used by a vendor in a form, 
filled out by the information requester. In one embodiment, the information requester is a "gift giver" and the provider is a "gift receiver". 
The gift giver is requesting shipping and other information from the gift receiver, who can grant one of his personas to the particular gift 
giver. The information, along with billing information from the gift giver, is used to fill out a vendor online form. 
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method for online information sharing for 
completing electronic forms 

Background of the Invention 

5 The present invention relates generally to computer software for filling out 

form documents over a computer network. More particvilarly, the present invention 
provides a method and system for sharing information among users for the purpose of 
automatically filling out fields in an electronic form document. 

The present invention describes a process for purchasing goods and services 

10 over an electronic computer network, namely the World Wide Web, for the purpose 
of Gift Shopping. Gift Shopping is defined as the act of buying a good or a service 
(the Product) for another person. Within the scope of the electronic computer 
network. Gift Shopping entails that the Gift Giver release personal information 
pertaining to the billing of the Product, and that the Gift Recipient release personal 

15 information pertaining to the shipping, size, and type of the Product. 

Thus, it is desirable to be able to share personal information with other users 
on a network. In such a system, a gift giver, for example, can access certain items of 
information, collectively referred to as a persona, which a gift receiver has indicated 
can be accessed by others. A user can have a number of personas, each one used by a 

20 group of other users or one other user. 
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Summary of the Inventtqn 

To achieve the foregoing, methods, apparatus, and computer-readable 
mediums are disclosed which provide an online shopper can share information with 
intended gift receivers. The information sharing can be used on numerous non- 
5 affiliated sites. That is, the sites at which the goods are purchased do not have to be 
within, for example, a portal's shopping mall or any type of "walled garden." Thus, 
the online gift giver can access information of gift receivers from a wide variety of 
non-associated and non-affiliated sites. While there are features similar to 
information sharing udthin restricted online shopping malls and networks of sites, 

1 0 information sharing outside these confines is presently unavailable. 

The present invention is a technique use to gather information from different 
sources to be used to automatically fill in online forms. The information is collected 
using a persona of an individual. A persona is created by filtering a larger set of raw 
data for that user so that only certain fields are allowed to be seen and used by others. 

1 5 An individual can have several personas, each assigned to a particular other 

individual, such as a family member or a fiiend. The individual allowing one of his 
personas to be shared is the information provider and the user requesting the 
information is the information requester. The information is taken from both the 
provider and requester, and used by a vendor in a form, filled out by the information 

20 requester. In one embodiment, the information requester is a "gift giver" and the 
provider is a "gift receiver." The gift giver is requesting shipping and other 
information from the gift receiver, who can grant one of his personas to the particular 
gift giver. The information, along with billing information from the gift giver, is used 
to fill out a vendor online form. 

2^ In oiie aspect of the invention a method of allowing an information requester, 

such as a gift giver, to access data from an information provider, such as a gift 
receiver, in order to complete an online merchant form is described. A filtered data 
set is created that contains data the information provider is willling to share with 

2 
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particular third-party users, including the information requester. An online merchant 

form is retrieved from a merchant or service provider site upon request by an 

information requester, the online merchant form having numerous fields. Data fixjm 

the information requester is inserted into the appropriate fields in the fonn, such as 

5 billing information. Access to the filtered data set is granted by the infonnation 

provider to the infonnation requester. This enables data from the filtered data set to 

be inserted into the appropriate fields in the form, such as shipping infonnation. The 

online forni being filled out is from an online merchant or service provider that is not 

necessarily affiliated with other online merchants, such as being in an online shopping 

1 0 mall, a " v/alled garden," or network of sites associated with a portal. 
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Brief Description of the Drawings 

The invention will be better understood by reference to the following 
description taken in conjunction with the accompanying drawings in which: 

FIG. 1 A is a diagrammatical representation of a system for automatically 
5 filling in electronic form documents in accordance with one embodiment of the 
present invention. 

FIG. IB is a block diagram showing components of a server enabling the 
automatic insertion of data in to an electronic form on a remote computer in 
accordance with one embodiment of the present invention. 
10 FIG. 2 is a flow diagram of a process for automatically filling in an electronic 

form document in accordance with one embodiment of the present invention. 

FIGS. 3A, 3B, and 3C are table diagrams showing the fleld names and format 
of registered user data in accordance with one embodiment of the present invention. 

FIG. 4 is a sequence diagram outlining a process of conducting purchasing 
15 gifts over a distributed network in accordance with one embodiment of the present 
invention. 

FIG. 5 is a flowchart describing a privacy negotiation for gathering 
information associated with purchasing gifts over a distributed network in accordance 
with one embodiment of the present invention. 
20 FIG. 6 is a block diagram showing the various parties and possible message 

passing between the parties in accordance with one embodiment of the present 
invention. 



4 



wo 00/54203 



PCT/USOO/06476 

Detailed Descrtptton 



Reference will now be made in detail to a preferred embodiment of the 
invention. An example of the preferred embodiment is illustrated in the 
accompanying drawings. While the invention will be described in conjunction with a 
5 preferred embodiment, it will be understood that it is not intended to limit the 
invention to one preferred embodiment. To the contrary, it is intended to cover 
ahematives, modifications, and equivalents as may be included within the spirit and 
scope of the invention as defined by the appended claims. 

A method and system for automatically filling in electronic forms on a 

1 0 computer and not requiring a user to download or install any resident software on the 
computer is described in the various figures. As the presence of merchants and 
services increases on the Internet, electronic commerce or e-commerce will grow. 
More and more consumers will resort to the Internet, for example, to purchase goods 
and services for themselves or others (e.g., gift shopping). This will typically require 

1 5 the consumer/user to provide at least some data, either the users own or another 
individuals, to the merchant typically through filling out an electronic form having 
various fields, most commonly names, addresses, credit card numbers, phone 
numbers, etc. For consumers purchasing goods from numerous merchant sites and 
possibly using different computers (e.g. using a computer at work, using another 

20 computer at home, and yet another one while travelling), manually filling in these 
forms repeatedly can become tedious and inefficient. The present invention seeks to 
alleviate the burden of filling in electronic forms, while informing the consumer/user 
of privacy precautions taken by a particular merchant site, and not require the user to 
download any resident software. Inherent in the latter feature is allowing the 

25 consumer to use the processes of the present invention from any computer connected 

to the network, the Internet in particular. 

The present invention uses a remote server or "privacy bank," a novel 

electronic resource that responds to requests for data by preparing and transmitting a 

5 
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specialized document in the form of a JavaScript. This JavaScript is formed 

dynamically by the privacy bank upon receipt of the request for data. The JavaScript 

created by the privacy bank is a "profile" or mapping between field names in a 

particular form the user needs to fill in at a particular merchant site (e.g. 

5 " www.fishermanstore.com" ) and standardized field names stored in the privacy 

bank server. Once the user's browser program is served this profile fi-om privacy 

bank, most of the fields in the fishermanstore form are automatically filled in. In the 

described embodiment, the user becomes a member of the privacy bank resource by 

providing personal information, also referred to as the raw data, to privacy bank once. 

10 This raw data can be updated fi-om time to time by the user if desired. In addition, 

several filtered raw data sets or "personas" can be created for use by others who may 
need to access the user's information. In another embodiment, the user can enter 
privacy rules or requirements once when initially becoming a member. The user does 
not need to download any software fi-om privacy bank or any other resource. In the 

15 described embodiment, the merchant (e.g. The Fisherman Store) becomes an affiliate 
member of the privacy bank network by providing a sample document of its form or 
forms. Privacy bank can then build a mapping between fields in the merchant's form 
and the standardized fields in its own database. 

FIG. 1 A is a block diagram of a system for automatically filling out electronic 

20 form documents in accordance with one embodiment of the present invention. A 
number of end-user computers are shown on the right side of the diagram. These 
computers can be client computers in a network with access to the Internet or be part 
of an intranet. In the described embodiment an end-user computer 102 is a stand- 
alone computer vAih access to the Internet and contains an Internet browser program, 

25 a browser window for which is shown at 1 04. In the center of the diagram is a 

number of Web servers. A particular Web server 1 06 is a server for a merchant Web 
site, such as www.fishennanstore.coni to which users or consumers can visit to 
purchase goods online over the Internet. On the left side of the diagram is a 
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specialized electronic resource referred to in the described embodiment as a privacy 
bank server computer 108, also connected to the Internet. 

The process of automatic electronic form completion begins with a user 
downloading the form from a Web site such as fishermanstore site. Returning to FIG. 
5 1 A, a user/consumer on computer 1 02 (" user 1 02" ) opens a browser window 1 04 in 
an Internet browser program such as Netscape Navigator or Internet Explorer, 
depicted by arrow 1 10. User 102 then goes to www.fishermanstore.com shown by 
arrow 1 12 via the browser and decides to purchase goods. User 102 then downloads 
from the Web site contained on Web server 106 an electronic purchasing form that 

1 0 needs to be completed as depicted by arrow 1 14. A purchasing form 1 1 6, typically an 
HTML document, is returned and downloaded into and displayed in browser window 
104. At this juncture, user 102 would normally have to "manually" fill in each field 
in purchasing form 1 16. Much of this information is typically standard: name, 
address, phone number, payment method, user email address, etc. In accordance with 

15 one embodiment of the present invention, user 102 can "click" on a privacy bank 
icon or button in form 116 and have the form automatically filled in. 

As stated earlier, it is assumed in this discussion that 
www.fishermanstore.com is registered with and thus an affiliate member of the 
privacy bank service assessable from privacy bank server 108. Being an affiliate 

20 member of the privacy bank service, purchasing form 116 contains a privacy bank 
icon or button 118. By clicking on privacy bank icon 1 1 8, user 102 essentially 
completes a process for automatically filling in form 1 16 by transparently 
transmitting a completed form to the privacy bank service on server 108, depicted by 
an arrow 120. The information needed for filling in the form is transmitted to user 

25 102 once form 1 1 6 (an HTML document) is parsed, which occurs when form 1 1 6 is 
downloaded. This process is described in greater detail in FIG. 4. User 102 informs 
privacy bank server 108 of the identity of the user and of which Web site and which 
form on that Web site (if more than one) the xiser wishes to have filled in. This 
information is transmitted to privacy bank server 108, unbeknownst to user 102, when 
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form 1 16 is downloaded. Techniques for accomplishing this are described below. 
Once privacy bank server 108 receives a request from registered user 102 (by virtue 
of an external link in form 116 executed when the form is parsed by user 102), it 
begins preparing information needed to fill in form 1 16 on user computer 102. In the 
5 described embodiment, the information sent to user computer 1 02 is a JavaScript 
program 124 referred to as a "profile." Explained briefly, this profile contains a 
mapping of privacy bank standardized fields and fields in purchasing form 116 and 
"raw," generally personal, data associated with user 102. The content of this profile 
and JavaScript program in general is described in greater detail in FIGS 7A and 7B 

10 below. Once received by the browser program on user computer 102, the filled out 
purchasing form 1 16 is displayed to user 102 as depicted by arrow 126. This occurs 
when user 102 presses or clicks on privacy bank icon 118. The information needed to 
complete form 1 16 is already resident in the browser program. At this juncture, user 
102 can decide whether to proceed vwth submitting the form (typically after filling out 

15 a few more fields such as which items to purchase, quantity, etc.) or declining to 
submit the form, perhaps after reviewdng the fishermanstore's Web site privacy 
safeguards or for any other reason. 

FIG. IB is a block diagram showing components of a privacy bank server 
enabling the automatic filling in of electronic forms on a remote user computer. A 

20 privacy bank server, such as server 108 in FIG. 1 A, contains several functional and 
storage components needed for compiling the data needed for filing in a form, such as 
form 1 16. Shown in FIG. IB are four major components of a privacy bank server in 
the described embodiment. These components and storage areas include a raw data 
profile storage area 128, a form mapping storage area 130, a negotiation history 

25 module 1 32, and a shippable code constructor 1 34. Raw data profile storage area 1 28 
contains sets of data relating to registered users of the privacy bank service, one set or 
profile shown in area 1 36. A registered user has a unique account number that can be 
used as an identifier and a password, shown in an area 138. The standard field names 
set by the privacy bank service, discussed in greater detail in FIGS. 8A, 8B, and 8C, 

8 



wo 00/54203 " PCTAJSOO/06476 
are paired with a user entered data string (such as first name or home street address), 

followed by a use-preference condition. This data is contained in an area 140. 
Another profile for another registered user is shown in an area 142. Each registered 
user has a similar raw data profile. 
5 Form mapping area 130 includes multiple form mappings, an example of 

which is shown in an area 144. Each electronic fomi that is registered with the 
privacy bank service by an onlme merchant or seller (Le. an affiliate member) has a 
form mapping. A privacy bank standard field name, as discussed below in FIGS. 3 A, 
3B, and 3C, and as mentioned above in area 140, is matched or mapped with a "non- 
10 standard" field name fi-om the electronic form registered with the service. For 

example, a non-standard field name for a person's last name could be " Last Name," 
" Surname" or simply "Last." Different forms use different variations of names for 
this field and for other fields. This would be mapped against the privacy bank 
"standard" field name, which in the described embodiment, is "PersoiiName.Last." 
1 5 Also contained in area 146 is a practice-preference condition provided by the online 
merchant or seller when registering the form. As with the use-preference condition in 
area 140, this condition is used by negotiation history module 150 and shippable code 
constructor 1 34, and is discussed in greater detail below in FIG. 7. Another mapping 
148 having the same format for another registered form follows area 144. 
20 Negotiation history module 132 is used to determine which fields in the 

electronic form will be automatically filled in by the privacy bank server. A process 
associated with negotiation history module 132 is described in greater detail in FIG. 
7. Module 132 includes multiple negotiation objects, an example of which is shown 
in an area 150. In the described embodiment, each negotiation object corresponds to 
25 one "non-standard" field in the form. Described briefly, negotiation object 150 

contains information as to whether the field in the form should be filled in based on 
privacy and use preferences set by the user (as conveyed in use-preference condition 
in area 140) and compared to intended practices (as conveyed by practice-preference 
condition in area 146). This comparison is performed in the negotiation history 
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module, which includes a negotiator or comparator for comparing these conditions. 

Specific conditions in the described embodiment are described below. If it is 

determined that the non-standard field in the form will be filled in, a data string, 

shown in area 140, will be included in negotiation object 150. Shippable code 

5 constructor 134 accesses component 132 and storage areas 128 and 130, to derive a 

software module to be transmitted to a user computer. In the described embodiment, 

the software module is a JavaScript program which is transmitted to and executed by 

a browser in the user computer, thereby inserting the data strings into the form fields. 

FIG. 2 is a flow diagram of a process for automatically filling in electronic 

1 0 forms in a computer network in accordance with one embodiment of the present 
invention. The process described below can be performed in a configuration of 
servers and computers as described in FIG. 1 A above. At a step 202 an online 
user/consumer desiring to purchase certain goods on the Internet downloads an 
electronic form for making a purchase into the user's browser program. At step 204 

1 5 the browser parses the electronic form content, typically an HTML document, to 
identify all external links. As is commonplace for Web pages, the HTML contains 
links to other external Web sites from which content or other types of data is 
retrieved. In many instances, a Web page is a composite of different components 
from various sites embedded in a core HTML document. An example is an external 

20 link to an ad server to retrieve a banner ad component of a core HTML document. In 
this case, the electronic form can be seen as a core HTML document. This parsing is 
done automatically by the browser and is a well known feature. 

At step 206 the browser identifies an external link to the privacy bank server. 
In the described embodiment, this link will necessarily be present since the Web site 

25 is an afifiUated site of the privacy bank service network of registered sites. A 

description of what "registered" implies in this context is described in greater detail 
below. At step 208, the browser executes the external link to connect the browser to 
the privacy bank server. The external link is referred to in the described embodiment 
as a shippable code link to the privacy bank server. The shippable code in this 
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context is a JavaScript program that is transmitted from the privacy bank server to the 
user computer and browser. This shippable code enables the electronic form to be 
filled in automatically in a process that is described in greater detail below. At step 
210, once the privacy bank server has been contacted via the shippable code link in 
5 the electronic form, the privacy bank server determines whether the user computer or 
browser has a valid state identifier, referred to as a " cookie" , previously assigned to it 
by the privacy bank server. A cookie is an identifier assigned by a Web site, whether 
a Web server or a server such as the privacy bank server, to a user/visitor when the 
user visits the Web site for the first time in a given session (the time from which a 

1 0 user logs onto the Web and the time he or she exits the Web by exiting the browser). 
The cookie, assigned by a Web site, belongs to a particular user. In the described 
embodiment, the user keeps this cookie during its session (a temporary cookie) and if 
the user goes back to that Web site during that session, it shows the Web site that 
cookie from which the Web site can identify the user and retrieve characteristics of 

1 5 that user from its data repository. As is known in the art of Internet application 

programming, cookies can also be permanent in that they subsist with a user after the 
user has logged off the browser and can be used again in a new session. The concept 
and implementation of cookies themselves are well known in the field of Internet and, 
more generally, computer network programming. 

20 If the privacy bank server detemaines that the user computer or browser does 

not have a valid cookie, it implies that the user has not yet logged into the privacy 
bank service. If so, control goes to step 212 where the privacy bank server retrieves a 
login sequence code. This code will trigger a login sequence and enable the user to 
log in to or register with the privacy bank service at a later step in the process, as 

25 described in greater detail below. At step 2 1 4, the privacy bank server forms a 

completed package of shippable code containing the retrieved login sequence code, 
such that the login sequence will be triggered at a later step in the process. At step 
222, the browser retrieves this completed package of shippable code from the privacy 
bank server. The shippable code is then stored in the browser residing on the user's 

11 
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computer, and is executable upon a user trigger, which is described in greater detail 
below. 

If the privacy bank server determines that the user/browser making contact by 
downloading the electronic form and executing the external link has a valid cookie, 
5 control goes to step 216 where the privacy bank server gets and reads the user's 

cookie. In this context, having a valid cookie indicates that the user has already gone 
through the login sequence recently, for example during the existing Internet session, 
and thus it is not necessary for the user to go through the login sequence again. By 
reading the user's cookie, the privacy bank server can determine who the user is and 

1 0 thus can retrieve the user's raw data stored by privacy bank. The contents and format 
of this raw personal data is described in greater detail in FIGS. 8 A, 8B, and 8C below. 
At step 21 8, the privacy bank server retrieves the user data for the user identified by 
the valid cookie. The privacy bank server couples this user data and an identifier, 
such as a URL (uniform resource locator), to determine how the electronic form 

1 5 document should be filled. At step 220, the privacy bank server forms a completed 
package of shippable code (item 124 in FIG. 1 A) containing the user data that will be 
used to fill out the form document. In the described embodiment, this shippable code, 
referred to as a profile, is in the form of a JavaScript program. This shippable code is 
formed from information in the privacy bank memory that will enable the form 

20 document to be filled out automatically at a step later in the process. At step 222 the 
browser receives the shippable code, or profile, firom the privacy bank server, and 
now has access to it on the user computer, if desired by the user. This profile is stored 
in the browser residing on the user's computer, and is executable upon a user trigger. 
Assuming the user wants to have the electronic form automatically filled out 

25 using privacy bank, he or she executes a user trigger. In the described embodiment, 
this trigger occurs when the user clicks on an " autofill" button contained in the form 
and associated with privacy bank at step 224. By clicking on the autofill button, the 
user allows the browser to execute the shippable code or profile stored thereon. At 
step 226, the shippable code determines whether it contains user data which would 

12 
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permit it to fill out the form document. If user data is contained within the shippable 

code residing on the browser, control goes to step 234 where the browser utilizes the 

shippable code and user data to fill out the electronic form document. Of course, user 

data being present in the shippable code is dependent upon the browser having a pre- 

5 existing valid cookie when the form document was initially retrieved, as described 

above. 

If, however, user data is not contained within the shippable code residing on 
the browser, control goes to step 228 where the login sequence is initiated in order to 
identify the presently unknown user. The shippable code utilized by the browser in 

1 0 this step contains the login sequence code, which is a result of the browser not having 
a pre-existing valid cookie when the form document was initially retrieved, as 
described above. Once the user completes the login sequence at step 228, the privacy 
bank server assigns a cookie to the user/browser thereby enabling it to recognize the 
user and messages from the user's browser in subsequent transactions. At step 230, 

1 5 the privacy bank server retrieves the user data for the identified user, couples this user 
data and an identifier, such as a URL (imiform resource locator), to determine how 
the electronic form document should be filled, and forms a completed package of 
shippable code containing the user data that will be used to fill out the form 
document. This step is substantially similar to steps 218 and 220, as described above. 

20 At step 228, the browser receives the shippable code, or profile, from the privacy 

bank server, and now has access to it on the user computer. This shippable code now 
contains user data that allows the form document to be filled out automatically. At 
this stage, control proceeds to step 234, where the browser utilizes the shippable code 
and user data to fill out the electronic form document. Further input fi-om the user, 

25 such as re-clicking on the *' autofill" button, is not required. In other words, once the 
user properly completes the login sequence, the form is then filled out automatically, 
and it is not necessary for the user to click on the "autofiU" button again. 

At step 236, the user visually examines the filled out form and the privacy 
features offered by the Web site and decides whether the form is acceptable. If the 
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user finds that the form needs further adjustment, the user adjusts the document at 
step 238. This may be done manually, or through any supplemental automated 
process, such as a client-based macro. This can involve filling in fields that could not 
be filled in by the profile sent by the privacy bank server (in other words, fields that 
5 could not be filled out fi-om the raw data). Such fields can include, for example, 
which items being purchased and the quantity of items. It can also include updated 
personal information such as a new address or credit card number. In this case, the 
user simply types over the information already in the fields. Control then returns to 
step 236, which is satisfied presumably after going through step 238 once. At step 

1 0 240 the browser submits the filled out electronic form eventually sending it to the 
merchant's Web server once the user clicks on a Submit form button in the browser 
window.. In the described embodiment, the filled out form is first sent to the privacy 
bank server unbeknownst to the user or at least transparent to the user. The 
completed form is received and examined by the privacy bank server which updates 

1 5 its raw data repository to reflect any changes the user may have made to his or her 
personal information. The privacy bank server then posts a message back to the user 
computer (according to HTTP protocol the server must send a message back to the 
user computer when it receives an HTML document from it). In the described 
embodiment, the message it sends back or posts to the user's browser is similar to a 

20 " Click Here To Continue" type screen to the user. Hidden behind this message is the 
completed form that was sent to the privacy bank server. Presxmiably, the user will 
click to continue and by doing so transmits the hidden completed form to the 
merchant's Web server. In other preferred embodiments, the completed form is sent 
to both the privacy bank server and the merchant's Web server at the same time. In 

25 yet another preferred embodiment, the completed form is posted automatically fi*om 
the privacy bank server directly to the merchant's site without any additional input 
from the user. At this stage the automatic form filling process is complete. 

FIGS. 3A, 3B, and 3C are high-level table diagrams showdng how fields 
containing the raw data and preferences for a user are organized on the privacy bank 

14 
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server in accordance with one embodiment of the present invention. A top-level User 
table 302 has four columns: User 304, Category 306, Type 308, and Short display 
name 3 1 0. User Table 302 has four areas of data under column User 304 represented 
by four rows: Home 3 1 2, Work 3 1 4, Billing 3 1 6, and Shipping 318. In the described 
5 embodiment, the user is presented with these four areas of data when registering with 
the privacy bank service and enters information by going through each of these data 
areas. Skipping Category 306 for the moment, colunm Type 308 takes the raw data 
tree down one level from the top level represented by table 302. For example, the 
Type for data area Home 3 12 is Info. This performs as a pointer or link to an Info 

10 table 320. The first colunm 322 of table 320 is labeled Info but the other three 

columns are the same as shown in table 302; that is, Category 306, Type 308, and 
Short display name 3 1 0. 

At table 320, the user begins entering data that will be used for her home 
information and for Shipping since data area 3 1 8 for Shipping in table 302 also has an 

1 5 Info in its Type column 308. A Name row 322 has in its Type column 308 a 

reference to yet another table PersonName, shown as table 324. Similar to table 302 
and 320, PersonName table 324 has a first column labeled PersonName and the same 
three columns as the other tables. All five data areas in PersonName table 324: 
Prefix, First. Middle, Last, and Suffix have as a Type a primitive type referred to as 

20 Text in the described embodiment. Text represents a data string that is the actual data 
item stored in the privacy bank server. By examining the Type column 308 of each of 
the data areas, a user enters all the raw personal data. An actual data item is entered 
at each Type box containing Text, indicating a primitive type, or a leaf node when 
viewed as a u-ee structure. If the Type column does not contain " Text," another table 

25 exists that refines the data area fiirther. 

To follow another example, under the data area Billing 316 shown in table 
302, its Type 308 indicates Billlnfo and not Text. A table Billlnfo has six further data 
areas, none of which have a Text Type, so no actual data values can be found at this 
level. Taking the CreditCard data area as an example, its Type indicates 

15 
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"CreditCard." Table CreditCard, shown in FIG. 3C, has four data areas: Type, 
Number, ExpMonth, and Exp Year, all of which are of Type Text, which contain 
actual data values. 

Short display name column 3 10 contains a string that is displayed to the user 
5 through a user registration graphical user interface of the described embodiment. The 
xiser follows the data tree via a user interface using the Short display name strings as 
field names or guides to entering the data. The data areas that have primitive Types, 
which in the described embodiment is Text, are the privacy bank field names that are 
mapped with the legacy field names in the electronic forms registered with the 
10 service. In the described embodiment, the privacy bank names include (in 
abbreviated form): 

PersonName.Prefix Address.Streetl PhoneNum.AreaCode 

PersonName.First Address.Street2 PhoneNum. Number 

15 PersonName.Last Address.City PhoneNum.Extension 

PersonName. Suffix Address.StateProv 

Address.PostalCode 

Address.Country 

20 Intemet.Email Employment.Employer 
Intemet-HomePage Employment.Department 

Employment.JobTitle 

CreditCard.Type 
CreditCard.Number 
25 CreditCard.ExpMonth 
CreditCard.ExpYear 

Category coliunn 306 is related to privacy settings set by the user and are tied 
to the preferences set by a user and defined in terms of the conditions as described 

30 above. The conditions or use thresholds in the described embodiment are marketing 
(targeted), system administration, personalization, research and development, and 
completion of activity (/.e. ordering). The Categories available in the described 
embodiment and as shown in the tables of FIGS. 3 A, 3B, and 3C, are Physical 
Contact Information, Online Contact Information, Demographic Data, and Financial 

35 Data. The relationship between the Categories and the conditions of the described 
embodiment can be described as a table five-row, four-column table (a 20 cell table) 
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where each condition is one row in the table and each Category is one column in the 
table. 

The present invention is an extension to a Form AutoFill Server using 
Personal Information sharing between Individuals to fill in electronic forms that are a 
5 part of the Form AutoFill and/or Gift Shopping service (the Service). The Form 
AutoFill Server is used to dispatch JavaScript code to the Web Browser, which 
enables the form to be filled. The Form AutoFill Server is a use of a Light Code 
Server, which serves Shippable Code Segments that are executed on the Web 
Browser's machine. By allowing Individuals to share their information with other 

1 0 Individuals, the Form AutoFill Server can provide data elements from two or more 
Individuals during a Privacy Negotiation (see Privacy Negotiation). 

The essence of Gift Shopping is that more than one Persona is used to fill a 
form. A Persona is defined as a data repository containing an Individual's personal 
information along with the privacy preferences that indicate how the Individual wants 

1 5 his or her data treated. Users of the Service may have multiple Personae as well as 
permission to use parts of other Individuals' Personae. There are two kinds of Gift 
Shopping that need to be covered. The first is Gift Shopping for people who are not 
necessarily subscribers/members of the Service. The second is Gift Shopping for 
people who are subscribers/members of the Service. In the latter case, we have to 

20 cover the mechanism for releasing permission to use a Persona of an Individual by 
another Individual for Gift Shopping purposes. 

FIG. 4 is a flow diagram of a process of an Individual (Gift Giver), who is Gift 
Shopping online and purchases a product from a Product Vendor that subscribes to 
the privacy bank service. They would like to buy a Product 401 that the Vendor is 

25 offering through an online form. The Gift Giver conmiands the browser to request a 
form fi-om the Vendor 402. The Vendor returns the document to the browser 403, 
which in tum displays the form to the Gift Giver 404. The Gift Giver clicks the 'Gift 
Shop' button 405, which is embedded in the HTML form at the Vendor's web site. 
The 'Gift Shop' button is the trigger that requests the Gift Recipient Selection form 
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from the Service 406. Since the intended Recipient is not a member of the Service, 
the Gift Giver may elect to create a new Persona or use a Persona that they have 
created in the past for Gift Shopping 409. The Gift Giver must fill in shipping 
information and any information related to the Product for a new Persona, During the 
5 selection of the Gift Recipient, a session parameter is set to identify which Persona to 
use for a Gift Recipient 410 when the Privacy Negotiation is to be conducted. After 
completing the Recipient creation, the browser is sent a document 41 1 that 
automatically requests the HTML form from the Vendor 412. The HTML form is 
returned to the browser 413, which again displays the form to the Gift Giver 414. 

10 Each time the form is loaded, it makes a request to the Form AutoFill Server, which 
conducts a Privacy Negotiation (see Privacy Negotiation) between electronic agents 
representing the Vendor, the Gift Giver, and the Gift Recipient if the Gift Giver is 
logged into the Service. JavaScript code is returned to the browser and executed there 
415, filling the form with the results from the Privacy Negotiation. The Gift Giver 

1 5 then submits the form by clicking a * Submit' button 4 1 6, which commands the 

browser to post the submission to the Service 417. After processing the submission, 
the browser receives a document 418, which conmiands the browser to submit the 
information to the Vendor's Web Server 419. 

A Gift Giver, who is Gift Shopping online, visits a Product Vendor that 

20 subscribes to the Service. The Gift Giver would like to buy a Product the Vendor is 
offering 401 . The browser requests an HTML form from the Vendor 402. The HTML 
form is returned to the browser 403, which is then displayed to the Gift Giver 404. 
The Gift Giver clicks the *Gift Shop' button 405, which makes the request for the Gift 
Recipient Selection form from the Service 406. The 'Gift Shop' button is embedded 

25 in the HTML form at the Vendor's web site. The Gift Recipient Selection Page is 
returned to browser 407, which is displayed to the Gift Giver 408. The Gift Giver 
may select a Recipient's Persona 409 that has been made accessible to the Gift Giver 
by the Gift Recipient (see Sharing Personae). The browser posts the Gift Recipient 
Selection to the Service 410. The browser is sent a document 41 1 that automatically 

18 
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requests the HTML form from the Vendor 412. The HTML form is returned to the 

browser 413, which again displays the form to the Gift Giver 414. Each time the form 

is loaded, it makes a request to the Service, which conducts a Privacy Negotiation 

(see Privacy Negotiation) between electronic agents representing the Vendor, the Gift 

5 Giver, and the Gift Recipient if the Gift Giver is logged into the Service. JavaScript 

code is returned to the browser and executed there 415, filling the form with the 

results fi-om the Privacy Negotiation. The Gift Giver then submits the form by 

clicking a 'Submit' button 416, which conmiands the browser to post the submission 

to the Service 417. After processing the submission, the browser receives a document 

10 418, which commands the browser to submit the information to the Vendor's Web 

Server 419. 

A Privacy Negotiation is the process of determining if a Vendor's stated 
Privacy Practices meet the requirements of an Individual's Privacy Preferences. A 
standard Privacy Negotiation is conducted between a single Information Buyer 

1 5 (Vendor's agent) and a single Information Seller (Individual's agent). In the case of 
Gift Shopping the Information Seller is a composite of Personae, which are separate 
Information Sellers. This composite Persona is achieved through a networked 
solution. A Message Router is used to direct BIDs from the Information Buyer to the 
Information Seller that they apply to. Each Information Seller connected to the Router 

20 has a mask assigned which controls which BIDs route to them based on what part of 
the Service's personal information data schema is being requested. This is the same 
model as an electronic computer network router, which routes data packets to a given 
machine based on the routing table of the router. Using this model allows for the 
individual Personae (Information Sellers) to respond to a BID based on the Privacy 

25 Preferences stored in the Persona that the BID gets routed to. 

FIG. 5 is a flow diagram of a Privacy Negotiation that begins by requesting if 
the Information Buyer 501, which is an agent for the Vendor in the current model, has 
any more BIDs. If Yes, the Privacy Negotiation records the BID in its transaction 
history and forwards it to the Information Seller 502, which is a Message Router in 
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the case of Gift Shopping. The Message Router receives the BID 503, and determines 
if it is intended for the Gift Giver's Information Seller or the Gift Recipient's 
Information Seller based on the mappings that define Gift Shopping 504. In the 
instance there is no gift shopping, control from 503 goes straight to 508 where it is 
5 determined if the BID meets certain privacy preferences of the information seller. 

Returning to step 504, if the BID is intended for the Gift Giver's Information Seller, it 
receives the BID 505. If the BID is intended for the Gift Recipient's Information 
Seller, it receives the BID 506. The BID is considered by the Information Seller that 
receives it 507. The Information Seller determines if the BID meets the Privacy 

10 Preferences stored inside of it 508. If the BID is accepted, an ACCEPT message is 

sent as the reply 509. If the BID is rejected, a DENY message is sent as the reply 5 1 0. 
The Message router receives the response from the Information Seller it sent the BID 
to and forwards the response to the Privacy Negotiation 511. The Privacy Negotiation 
records the response in its transaction history in step 5 12 and returns to step 501 . If 

1 5 the Information Buyer has no more BIDs, the Privacy Negotiation is complete. 

In order for an Individual (Gift Giver) to use another Individual's (Gift 
Recipient) Persona, the Gift Recipient must explicitly grant access to the Gift Giver. 
A Gift Giver may request access from a Gift Recipient, after which the Recipient may 
grant or deny access. A Gift Recipient may also add a Gift Giver without receiving a 

20 request. Once access is granted, the Gift Recipient is added to the Gift Giver's list of 
Gift Recipients for use while Gift Shopping. 

FIG. 6 is a block diagram showing the various parties and possible message 
passing between the parties in accordance with one embodiment of the present 
invention. The parties shown are the vendor or store merchant, a gift giver 

25 (information requester) and gift recipient (information granter). In between the 

parties is a message router that is part of the privacy bank server. A vendor sends out 
a BIDS which is routed by the message router. The BIDS billing portion is sent to the 
gift giver and the BIDS shipping information is sent to the gift receiver. Both the gift 
receiver and gift giver reply with either an Accept or Deny to the BIDS request. The 
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Accept or Deny messages from the parties are then sent to the Vendor. If the gift 

receiver sends a Deny message, he is indicating that he does not want to share his 

information with the gift giver. Although it is possible for the gift giver to deny the 

BIDS shipping request, it is unlikely since he is typically the one requesting the 

5 information from the gift receiver. Once the vendor receives the messages, it acts 

accordingly by either shipping out the goods or sending a message to the gift giver 

that the BIDS shipping information request was denied. 

Although the foregoing invention has been described in some detail for 

purposes of clarity of understanding, it will be apparent that certain changes and 

1 0 modifications may be practiced within the scope of the appended claims. 

Furthermore, it should be noted that there are alternative ways of implementing both 
the process and apparatus of the present invention. Accordingly, the present 
embodiments are to be considered as illustrative and not restrictive, and the invention 
is not to be limited to the details given herein, but may be modified within the scope 

1 5 and equivalents of the appended claims. 
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Claims 



What is claimed is: 



1 . A method of sharing infomiation in a computer network in which the 
5 information is used to fill in online forms, the method comprising: 

accessing a first primary data profile containing a non-filtered set of data 
corresponding to a first user; 

creating one or more secondary data profiles, wherein a secondary data profile 
contains a filtered set of data, wherein the filtered set of data is taken fi-om the first 
10 primary data file; and 

coalescing data from a secondary data profile and data from a second primary 
data profile to construct a third data set wherein the third data set is used to complete 
an online form such that certain data items required by the form relating to the first 
user are taken from the secondary data profile portion of the third data set. 

15 

2. A method of sharing information as recited in claim 1 wherein creating one or 
more secondary data profiles further comprises selecting particular data items fi-om 
the non-filtered set of data that the first user intends to share with one or more 
computer network users. 

20 

3. A method of sharing information as recited in claim 1 wherein creating one or 
more secondary data profiles fiirther comprises creating a secondary data profile for a 
specific computer network user. 

25 4. A method as recited in claim 3 wherein the specific computer network user is 
a gift giver and the first user is a gift receiver. 

5. A method as recited in claim 1 wherein a secondary data profile inherits 
privacy preferences fi-om data items m the first primary data profile. 

30 

6. A method as recited in claim 5 wherein privacy preferences attached to the 
secondary data profile determine how the secondary data profile will be used. 

7. A method as recited in claim 1 wherein coalescing data fi-om a secondary data 
35 profile and data fi-om a second primary data profile fiirther comprises taking data fi-om 
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the secondary data profile relating to shipping and specific characteristics of the first 
user and taking data from the second primary data profile relating to billing. 

8. A method as recited in claim 1 further comprising automatically filling in an 
5 online form with data fi-om the third data set once the first user has been selected by i 
second user. 



10 



9. A method as recited in claim 8 fiirther comprising requesting access to use the 
secondary data profile in response to a notification to a fill in an online fonn. 

10. A method as recited in claim 9 further comprising grantmg access to the 
secondary data profile thereby enabling a computer network user to fill in the online 
form. 



15 11. A method of allowing an information requester to access data from an 
information provider in order to complete an online merchant form, the method 
comprising: 

creating a filtered data set containing data the information provider is willling 
to share with particular third-party users, mcluding the information requester; 
20 retrieving an online merchant form upon request by an information requester, 

the online merchant form having a plurality of fields; 

inserting data from the information requester into a first subset of the plurality 
of fields; and 

granting access to the filtered data set by the information provider to the 
25 information requester so that data from the filtered data set is inserted into a second 
subset of the plurality of fields, wherein the online merchant form is from an online 
merchant not affiliated with any other online merchant. 

12. A method as recited in claim 1 1 wherein the online merchant is not associated 
30 with a network or group of other online merchants. 

13. A method as recited in claim 1 1 further comprising: 

dynamically updating the filtered data set by the information provider such 
that the information requester has access to only updated information. 



35 



14. A method as recited in claim 13 wherein the filtered data set can be updated 
by editmg an underlying un-filtered data set under the control of the information 
provider. 
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